Web services are on-line application programs developed and published over a network by service providers for meeting some business requirements. Once a Web service is published, other applications are able to access and use the service through the network. FIG. 1 is a schematic diagram showing Web service architecture in accordance with current technology. It can be seen from FIG. 1 that in the field of Web services, there are three kinds of components, that is, service providers 102, a registration proxy 104, and service requesters 106. The service providers develop Web services and describe the developed services to the registration proxy using a universal object description language, i.e. the Web Services Description Language (WSDL). This process is the Web service publishing process, wherein categories of registered Web service providers, interface features for accessing the Web services and various non-interface features, such as security requirements, transaction requirements and charge for using the Web services, are described with WSDL. It should be noted that the WSDL defines each Web service as a port and each port is used for representing a mapping from an abstract port type (i.e., portType) to a specific communication protocol for invoking a Web service.
A registration proxy 104 is used for providing a registration location for Web services. The registration proxy registers the Web services that have been published, categorizes these services based on the descriptions of the Web services, and provides discovery service. A registration proxy further includes a UDDI (Universal Description, Discovery and Integration) registration center 114, a WSIL (Web Service Inspection Language) registration center 124, a USML (UDDI Search Markup Language) registration center 144, and others, depending on the registration mechanisms.
A Web service requester requests interaction with a Web service through a SOAP (Simple Object Access Protocol) message, so as to invoke the service. Usually, before this invocation happens, it is necessary to discover a Web service that meets specific functional or other requirements on the registration proxy and locate a proper Web service implementation previously unknown to the requester based on the descriptions of the Web services. This process is performed by the service requester and the registration proxy. Because the discovery at the registration proxy and subsequent selection may result in a plurality of candidates, it may be necessary for the requester to make further selection among these candidates based on additional criteria, such as Quality of Service (QoS). In some cases, the selection process is still insufficient and it may be necessary to compare the actual invocation results of the remaining candidates to determine the best service implementation.
Since one Web service interface usually defines a plurality of correlative operations, sometimes it may be necessary to make a follow-up invocation on the same candidate that returned the best result as a further step of an online transaction process. For instance, the interface of an on-line bookstore Web service may consist of two on-line operations, that is, “queryBook” operation and “orderBook” operation, wherein the “queryBook” operation provides information about the names and prices of available books, while the “orderBook” operation implements the actual ordering transaction. In this case, a requester may invoke the “queryBook” operation of several candidate bookstore service implementations, compare the invocation results and select the Web service implementation that has the desired book while offering the lowest price. Then, the requester invokes the “orderBook” operation of the selected Web service implementation so as to complete the transaction process of book-ordering.
It can be seen that the whole process described above, consisting of service discovery, selection, invocation and result comparison as well as follow-up invocations, depends on the participation of the service requester. As a result, the invocations of these implementations are time consuming work for a requester, and lack reusability and adaptability.
U.S. Patent Publication No. 2004/0111525 proposed a mechanism for dynamic discovery and selection of Web service implementations at runtime without explicit requester control. Service requests are received from requesters and a portType, or other type identifier of operations that need to be supported by a Web service implementation, is identified. A discovery mechanism is invoked for querying service information sources to identify, from these sources, candidates that support the portType or operation identified. Then, a service object is generated using the selected Web service implementation candidates and a requester uses the service object to access actual service implementations. Although more reusability may be brought and the complexity of the discovery and selection process may be partly avoided by adopting the apparatus and method suggested by the proposed mechanism, the requester is only allowed to specify very limited discovery criteria (through service portType and operation name) and no selection criteria, which means that the selection process is completely controlled by the underlying mechanism. Further, the invention does not support invocation result comparison.
U.S. Patent Publication No. 2003/0204622 discloses another method for dynamically invoking a Web service. The method comprises assembling a collection of references to remote Web service implementations based on a common port type. A Web service implementation document for each referenced remote implementation in the collection is parsed to determine a list of ports through which the remote implementations can be invoked. Based on at least one of high-availability concerns, service quality concerns and economic concerns, a set of port selection rules is compiled and applied to the determined ports so as to select a specific one. Finally, a corresponding Web service may be invoked through the selected specific port. It can be seen that the disclosed method does not provide any way for the requester to explicitly specify its discovery and selection criteria when making a service invocation. And again, the method does not support invocation result comparison.
As a conclusion, the above-mentioned known solutions either let the requester handle all the complexity involved in the Web service discovery and selection process or take the process over wholly without allowing the requester any explicit control.